IBIS Macromodel Task Group Meeting date: 13 August 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Ken Willis Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Stephen Slater Maziar Farahmand Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz * Mike LaBonte SPISim: Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Michael M. noted that he had some technical questions about BIRD197.4 to review. Arpad noted that he would like to make time for this discussion since BIRD197.4 is scheduled for a vote at the IBIS Open Forum teleconference on September 06, 2019. ------------- Review of ARs: - None recorded in previous minutes. Two informal ARs below: - Arpad to inform the Open Forum of the August 6th ATM meeting's straw poll on interest in providing Level 1 and Level 4 IBIS-ISS parsers. - Done at the Open Forum meeting on August 9, 2019. - Bob to ask the ibischk developer for quotes on developing Level 1 and Level 4 IBIS-ISS parsers. - In progress. Bob will do this but not until after ibischk 7.0 is finished. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the August 06 meeting. Mike L. moved to approve the minutes. Bob seconded the motion. There were no objections. ------------- New Discussion: Interconnect Model syntax - questions about Aggressor_Only: Bob shared some Aggressor_Only syntax rule emails he had sent to the Interconnect task group mailing list. Bob noted the Aggressor_Only parser checking ambiguity issues he had brought up at the Open Forum meeting. If a particular Pin name were tagged as Aggressor_Only at one interface, was it implied that it was Aggressor_Only at every interface or was it a requirement to tag it as Aggressor_Only at every interface? Bob noted that the consensus was that it was not necessary to specify Aggressor_Only at all the interfaces. Walter agreed and noted that we might need a BIRD or editorial changes to clean up a few conflicting statements in this area. Bob noted that he had introduced another rule for the parser developer to enforce. If all the terminals in a model are marked as Aggressor_Only, then a warning will be issued. Walter agreed with this rule to generate a warning, but he noted that he could see why a model maker might create such a model. He noted that Aggressor_Only does not mean "this can only be used as an aggressor", but instead is defined to mean "this doesn't have all the possible aggressors that could contribute to me as a victim." He said it wouldn't be ideal, but the user could make the decision about how to use such a model. Bob referred to Figure 48 on page 308 of IBIS 7.0. He noted the example illustrates the ambiguity if a user wanted to run a simulation with a pin that is listed as Aggressor_Only in all models. He also noted that the paragraph that precedes the figure states that EDA tools are not expected to provide a user selection interface for Models in Interconnect Model Sets, so there would be no way for a user to choose amongst the models in the event a particular pin was marked as Aggressor_Only in all the models. Bob returned to the first topic of specifying Aggressor_Only only once. He noted that all of the examples in the spec specify Aggressor_Only at every interface. He also noted some problematic wording in the last sentence of page 306, with two confusing uses of "identified" in different contexts: Within any Interconnect Model, if a terminal line is identified as Aggressor_Only, then the corresponding terminal line associated with the same pin_name shall also be identified as Aggressor_Only. Walter agreed and suggested that the first instance of identified should be replaced with "marked", and the second should be replaced with "considered". The question was whether this required a BIRD or just an editorial change. Radek suggested that it might be good for the parser to provide the information when an unmarked terminal was considered Aggressor_Only because the line was marked Aggressor_Only elsewhere. Bob felt this might not be something the parser should flag at all, since it's legal. Walter noted that Bob had raised some important points, and that the time- sensitive issue was getting the right information to the parser developer. The parser should not expect/enforce Aggressor_Only being marked at every interface. The parser should produce a warning if all pins in a model are marked Aggressor_Only. Bob said he would review all of the examples and revert some to the earlier rules that didn't require Aggressor_Only to be marked at every interface. Arpad asked if we needed a BIRD or clarification for any of this. Bob said we were okay for now since we'd come up with the interpretation for the parser developer. Bob noted that we might need to revisit rules on pgs. 33, 34, 306 and 308 for clarity. Walter agreed to draft a list of his suggested changes and clarifications with respect to Interconnect Models and send it to ATM. Michael Mirmak's questions related to BIRD197.4 (from the Opens): Michael noted that some co-workers reviewing the BIRD had been confused by some of the language. He noted that the DC_Offset section mentions both step response and impulse response, and this had led some to believe step response was now also a valid input to the AMI model. Arpad noted that the input to the .dll is still an impulse response, and that step response was mentioned only in the context of explaining what the value of the DC_Offset parameter represented. No one else stated that they shared Michael's concern that this text was misleading. Michael's second question was related to the DC_Offset and how it might be used or affected by equalization in the Tx. Could the DC_Offset be changed by the Tx? Do we need to have DC_Offset allowed for the Tx, so it can do something with it? He noted that the text says, "if the impulse response is generated by differentiating the analog channel step response...". He said that would strip off any DC offset associated with a step response, but nothing prevented a Tx from artificially changing the IR and adding it back in. He noted that there was nothing wrong with the BIRD, but we might need to add to it in order to account for Tx processing. Arpad noted that, in the sentence Michael quoted, the words "analog channel" were important and had been added in response to questions Arpad had raised during the review of the BIRD. The original BIRD mentioned the waveform at the "rx pad", and it had been unclear whether we meant the analog channel waveform or perhaps the waveform input to Rx GetWave(). The "analog channel" text was meant to clarify that the DC_Offset captures the DC offset of the step response of the analog channel. This is sufficient for the AMI_Init() processing. If the Tx model wants to modify the offset of its GetWave() output waveform, the BIRD says nothing about that and the Rx has to be able to deal with that possibility during GetWave() processing. Fangyi noted that the DC_Offset parameter is for AMI_Init() processing only, so it's used by the LTI version of the model. If you want to use an LTI filter to model a Tx equalization, for example a Tx deemphasis design, you see that it won't change the DC_Offset. The absolute value of all the taps will sum to 1, so the DC offset would be unchanged. That's why it is an Rx only parameter. There might be some non-linearities that make the Tx output have a small DC offset, but that would need to be captured by Tx GetWave() processing. Walter agreed that for Init() processing the Tx does not need to know the DC_Offset. But he noted that it's conceivable that because of non-linearities the Tx GetWave() might want to adjust the GetWave() waveform's offset based on the value of DC_Offset. So, it might be useful to have DC_Offset as an In parameter for the Tx model, so it can use it when including some of the non-linearities of the FFE in the GetWave() output. He noted, however, that most FFE's don't amplify (taps sum to 1), so the output of Tx GetWave() couldn't exceed the rail voltage and the Tx probably can't saturate. But the only reason to consider any change to the BIRD would be to allow DC_Offset as an In to the Tx. Fangyi noted that even if there were non-linearities, in the real-world system the Tx would not know the value of the DC offset at the Rx pad. The Tx non- linearity might depend on the Rx termination, but we should model it that way if necessary. Walter asked if you wouldn't just model that by doing the step response and letting it capture the effects of the Rx termination. Arpad noted that if the termination wasn't a simple Ohm's law and instead involved saturated I/V curves, you wouldn't capture that accurately with a step response. Fangyi noted that a fundamental AMI assumption is that the algorithmic .dll processing is electrically isolated from the analog channel. If we say any of the algorithmic non-linearities are related to the analog channel then AMI breaks down. Michael M. noted that at this point the BIRD is limited to Init() processing, and the language is correct given all those assumptions. Therefore, he did not expect to push for any changes to the BIRD, but may introduce extensions in the future. - Walter: Motion to adjourn. - Fangyi: Second. - Arpad: Thank you all for joining. AR: Walter to draft an email listing proposed clarification language related to Interconnect Models. ------------- Next meeting: 20 August 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives